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Abstract 

Concurrency,  as  a  useful  feature  of  many  modern  programming  lan¬ 
guages  and  systems,  is  generally  hard  to  reason  about.  Although 
existing  work  has  explored  the  verification  of  concurrent  programs 
using  high-level  languages  and  calculi,  the  verification  of  concur¬ 
rent  assembly  code  remains  an  open  problem,  largely  due  to  the  lack 
of  abstraction  at  a  low-level.  Nevertheless,  it  is  sometimes  neces¬ 
sary  to  reason  about  assembly  code  or  machine  executables  so  as  to 
achieve  higher  assurance. 

In  this  paper,  we  propose  a  logic-based  “type”  system  for  the  static 
verification  of  concurrent  assembly  programs,  applying  the  “invari¬ 
ance  proof”  technique  for  verifying  general  safety  properties  and 
the  “assume-guarantee”  paradigm  for  decomposition.  In  particular, 
we  introduce  a  notion  of  “local  guarantee”  for  the  thread-modular 
verification  in  a  non-preemptive  setting. 

Our  system  is  fully  mechanized.  Its  soundness  has  been  verified 
using  the  Coq  proof  assistant.  A  safety  proof  of  a  program  is  semi- 
automatically  constructed  with  help  of  Coq,  allowing  the  verifica¬ 
tion  of  even  undecidable  safety  properties.  We  demonstrate  the  us¬ 
age  of  our  system  using  three  examples,  addressing  mutual  exclu¬ 
sion,  deadlock  freedom,  and  partial  correctness  respectively. 

Categories  and  Subject  Descriptors 

F.3.1  [Logics  and  Meanings  of  Programs]:  Specifying  and 
Verifying  and  Reasoning  about  Programs — assertions,  invariants, 
mechanical  verification’,  D.2.4  [Software  Engineering]:  Soft¬ 
ware/Program  Verification — correctness  proofs,  formal  methods’, 
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ory 
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1  Introduction 

The  Verifying  Compiler,  as  a  Grand  Challenge  [20]  to  the  pro¬ 
gramming  languages  community,  solicits  a  programming  frame¬ 
work  which  guarantees  the  correctness  of  a  program  before  run¬ 
ning  it.  The  criterion  of  correctness  ranges  from  type-safety,  which 
has  been  widely  applied  in  programming  practice,  to  total  correct¬ 
ness  of  critical  components,  whose  application  is  often  limited  by 
an  evaluation  of  the  cost  and  benefits  of  accurate  and  complete  for¬ 
malization. 

Whereas  it  is  difficult  to  ensure  correctness  for  sequential  systems, 
it  is  even  more  so  for  concurrent  systems  due  to  the  interaction 
and  interference  between  multiple  threads.  Much  existing  work 
has  explored  the  verification  of  concurrent  programs  using  high- 
level  languages  and  calculi  (e.g.,  CSP  [19],  CCS  [26],  CML  [37], 
TLA  [24]).  Unfortunately,  the  verification  of  concurrent  assembly 
code  remains  an  open  problem.  On  the  one  hand,  the  low-level  ab¬ 
straction  is  arduous  to  work  with;  On  the  other  hand,  the  extreme 
flexibility  offered  by  assembly  languages  is  tough  to  manage. 

Nevertheless,  any  high-level  program  or  computation  must  be  trans¬ 
lated  before  it  is  carried  out  on  actual  machines,  and  the  translation 
process  in  practice  is  invariably  anything  but  trivial.  It  is  at  least 
suspectable  that  the  guarantee  established  at  the  high-level  may  be 
invalidated  by  tricky  compilation  and  optimization  bugs.  Therefore, 
it  is  not  only  useful,  but  sometimes  necessary  to  reason  about  as¬ 
sembly  code  or  machine  executable  directly  so  as  to  achieve  higher 
assurance.  Furthermore,  certain  critical  applications,  such  as  core 
system  libraries  and  embedded  software,  are  sometimes  directly 
written  in  assembly  code  for  efficiency  and  expressiveness;  their 
verification  should  not  be  overlooked. 

Our  previous  work  [46,  47]  investigated  a  logic-based  approach  for 
verifying  assembly  code.  We  demonstrated  that  a  simple  low-level 
language  based  on  Hoare  logic  [17,  18],  namely  a  language  for 
certified  assembly  programming  (CAP),  can  be  used  to  certify  more 
than  type  safety;  and  with  help  of  a  proof  assistant,  semi-automatic 
proof  construction  is  not  unduly  difficult,  allowing  the  verification 
of  even  undecidable  program  properties.  Moreover,  the  machine- 
checkable  proofs  for  the  safety  of  the  assembly  code  directly  en- 
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Figure  1.  Syntax  and  verification  constructs  of  Simple  CAP. 


able  the  encapsulation  of  verified  CAP  programs  as  Foundational 
Proof-Carrying  Code  (FPCC)  [4,  15]  packages. 

In  this  paper,  we  extend  the  previous  work  on  CAP  to  the  domain 
of  concurrent  computation,  presenting  a  concurrent  language  for 
certified  assembly  programming  (CCAP).  The  computation  layer 
of  CCAP  models  a  simple  yet  generic  assembly  language  that  sup¬ 
ports  the  non-deterministic  interleaved  execution  of  two  threads. 
The  “type”  layer  of  CCAP,  as  is  the  case  of  CAP,  engages  the  cal¬ 
culus  of  inductive  constructions  (CiC)  [35]  to  support  essentially 
higher-order  predicate  logic  reasonings.  To  effectively  model  safety 
properties  and  the  interaction  between  threads,  we  adapt  and  apply 
established  approaches  for  reasoning  about  (high-level)  concurrent 
programs,  namely  the  “invariance  proof”  technique  [24]  and  the 
“assume-guarantee”  paradigm  [27,  23]. 

The  thread  control  in  CCAP  is  non-preemptive — a  thread’s  execu¬ 
tion  will  not  be  interrupted  until  it  explicitly  yields  control.  This 
non-preemptive  setting  is  very  useful  in  clearly  separating  thread  in¬ 
teraction  from  other  orthogonal  issues  of  the  verification  of  assem¬ 
bly  programs.  Furthermore,  besides  facilitating  simpler  presenta¬ 
tion  and  allowing  easier  understanding,  the  non-preemptive  setting 
is  also  more  fundamental,  because  even  preemptive  thread  controls 
are  essentially  implemented  with  help  of  non-preemption,  such  as 
the  disabling  of  interrupts. 

Non-preemption  also  introduces  extra  difficulties  which  have  not 
been  addressed  by  previous  researches  that  assume  preemption. 
Since  the  thread  control  will  not  be  interrupted  arbitrarily,  programs 
can  be  written  in  a  more  flexible  manner  (for  most  safety  proper¬ 
ties,  a  program  that  works  correctly  in  a  preemptive  setting  will 
also  work  correctly  in  a  non-preemptive  setting,  but  not  vice  versa). 
In  this  paper,  we  generalize  the  assume-guarantee  paradigm  by  in¬ 
troducing  a  notion  of  “local  guarantee”  to  accommodate  such  extra 
flexibility. 

It  is  worth  noting  that  CCAP  is  strictly  more  expressive  than  CAP — 
it  is  a  generalization  to  handle  more  problems  in  practice,  rather 
than  a  specialization  for  a  particular  problem  domain.  We  also  wish 
to  point  out  that  generating  FPCC  packages  for  CCAP  is  as  easy  as 
that  for  CAP,  although  a  detailed  account  of  which  is  omitted  due 
to  space  constraints. 

We  have  developed  the  language  CCAP  and  proved  its  soundness 
using  the  Coq  proof  assistant  [42].  The  implementation  in  Coq 
is  available  for  download  [43].  We  illustrate  the  usage  of  CCAP 
by  discussing  three  example  programs,  whose  safety  properties  of 


(C,  1 — >•  P  where 

ifi  = 

then  P  = 

jdf 

(C,(H,R),F)  where  C(f)  =F 

add  rj,ri,rf;F 

(C,(H,R{r^'^R(r,)+R(r,)|),F) 

movi  r^,w;I' 

(C,(H,R|r^-^w|),F) 

bgt  rj,r,,f;r 

(C,  (H,R),F)  when  Rjrj)  <  R(rj);  and 
(C,  (H,R),C(f ))  when  R(rs)  >  R(r,) 

Id  rj,ri(w);I' 

(C,(H,R|r^'^H(R(r,)+w)|),F) 
where  (R(rj)  -fw)  G  dom(H) 

St  rj(w),rj;F 

(C,(H|R(r^)+w^R(r,)|,R),F) 
where  (R(rj)  +w)  e  dom(]HI) 

Figure  2.  Operational  semantics  of  Simple  CAP. 


concern  are  mutual  exclusion,  deadlock  freedom,  and  partial  cor¬ 
rectness  respectively.  For  ease  of  understanding,  we  present  the 
central  idea  by  modeling  a  simplified  abstract  machine,  and  give  a 
generalized  account  in  the  appendix. 

2  Background 

In  this  section,  we  review  some  key  techniques  used  in  the  design 
of  CCAP.  Section  2. 1  presents  a  simplified  CAP  in  a  nutshell.  Sec¬ 
tion  2.2  discusses  informally  the  technique  of  invariance  proof  for 
proving  safety  properties,  along  with  its  connection  with  the  syn¬ 
tactic  approach  to  type  soundness  [44].  A  brief  introduction  to  the 
assume-guarantee  paradigm  is  given  in  Section  2.3. 

2.1  Simple  CAP 

As  suggested  by  its  name  (a  language  for  certified  assembly 
programming),  CAP  is  an  assembly  language  designed  for  writ¬ 
ing  “certified  programs”,  i.e.,  programs  together  with  their  formal 
safety  proofs.  Here  we  introduce  Simple  CAP  with  a  limited  in¬ 
struction  set  for  ease  of  understanding.  In  particular,  we  omit  the 
support  for  higher-order  code  pointers  (realized  by  an  indirect  jump 
instruction  in  the  original  CAP),  instead  discussing  its  handling  in 
Section  6.3. 

This  language  is  best  learned  in  two  steps.  Step  one  puts  aside  the 
“certifying”  part  and  focus  on  a  generic  assembly  language  (see  the 
upper  part  of  Figure  1).  A  complete  program  consists  of  a  code 
heap,  a  dynamic  state  component  made  up  of  the  register  file  and 
data  heap,  and  an  instruction  sequence.  The  instruction  set  is  mini¬ 
mal  but  extensions  are  straightforward.  The  register  file  is  made  up 
of  8  registers  and  the  date  heap  is  potentially  infinite.  The  opera¬ 
tional  semantics  of  this  language  (Figure  2)  should  pose  no  surprise. 
Note  that  it  is  illegal  to  access  a  heap  location  (label)  which  does 
not  exist,  in  which  case  the  execution  gets  “stuck.” 

In  step  two,  we  equip  this  language  with  a  construct  T*  {Code 
Heap  Specification)  for  expressing  user-defined  safety  requirements 
in  Hoare-logic  style  (see  the  lower  part  of  Figure  1).  A  code 
heap  specification  associates  every  code  label  with  an  assertion, 
with  the  intention  that  the  precondition  of  a  code  block  is  de¬ 
scribed  by  the  corresponding  assertion.  CAP  programs  are  writ¬ 
ten  in  continuation-passing  style  because  there  are  no  instructions 
directly  in  correspondence  with  the  calling  and  returning  in  a  high- 
level  language.  Hence  postconditions  in  Hoare  logic  do  not  have  an 
explicit  counterpart  in  CAP;  they  are  interpreted  as  preconditions 
of  the  continuations. 

To  check  the  validity  of  these  assertions  mechanically,  we  im- 


'PhC  'i'|-{a}I  (aS) 
'i'h{a}(C,S,I) 


by  the  code  heap  specification.  Here  the  symbol  “D”  is  used  to  de- 
(PROG)  note  logical  implication.  Also  note  the  slight  notational  abuse  for 
convenience — state  meta-variables  are  reused  as  state  variables. 


>Ph{a,}Ii  Vie{l...n} 
'I'l-  {fi 


(CODEHEAP) 


VS.  aSDaiS  where 'i'(f)  =  ai 
'i'|-{a}jdf 


(JD) 


VH.  VR.  a  (H,R)  D  a'  (H,R{rrf  R(rs)  +R(rr)}) 
'Ph  {a'}I 

'Ph  {a} add  rrf,rs,rGl 

Figure  3.  Sample  inference  rules  of  Simple  CAP. 


plement  all  CAP  language  constructs  and  their  semantics  using 
the  calculus  of  inductive  constructions  (CiC)  [42,  35],  which  is 
a  calculus  that  corresponds  to  a  variant  of  higher-order  predicate 
logic  via  the  formulae-as-types  principle  (Curry-Howard  isomor¬ 
phism  [22]).  We  further  define  our  assertion  language  (Assert) 
to  contain  any  CiC  terms  which  have  type  State -^Prop,  where 
Prop  is  a  CiC  sort  corresponding  to  logical  propositions,  and  the 
various  syntactic  categories  of  the  assembly  language  (such  as 
State)  have  been  encoded  using  inductive  definitions.  Although 
CiC  is  unconventional  to  most  programmers,  we  implement  the 
CAP  language  using  the  Coq  proof  assistant  [42]  which  implicitly 
handles  the  formulae-as-types  principle  and  hence  programmers 
can  reason  as  if  they  were  directly  using  higher-order  predicate 
logic.  (Logic  is  something  a  programmer  has  to  learn  if  formal 
reasoning  is  desired.  Higher-order  logic  appears  to  be  fairly 
close  to  what  people  usually  use  to  reason.)  For  example,  a 
precondition  specifying  that  the  registers  ri,  r2  and  r3  store  the 
same  value  is  written  in  Coq  as  the  assertion  (state  predicate) 
[s:State]  let  (H,R)=s  in  R(rl)=R(r2)  /\  R(r2)=R(r3) 
where  [s :  State]  is  a  binding  of  variable  s  of  type  State,  let  is 
a  pattern  matching  construct,  and  /\  is  the  logical  connective  A. 
Proving  the  validity  of  propositions  is  done  by  using  tactics  which 
correspond  to  logical  inference  rules  such  as  “A-introduction.” 

To  reason  about  the  validity  of  an  assertion  as  a  precondition  of  a 
code  block,  we  define  a  set  of  inference  rules  for  proving  specifica¬ 
tion  judgments  of  the  following  forms: 


An  instruction  sequence  preceded  by  an  addition  is  safe  (rule  ADD) 
if  we  can  find  an  assertion  a'  which  serves  both  as  the  postcondition 
of  the  addition  (a'  holds  on  the  updated  machine  state  after  execut¬ 
ing  the  addition,  as  captured  by  the  implication)  and  as  the  precon¬ 
dition  of  the  tail  instruction  sequence.  A  programmer’s  task,  when 
proving  the  well-formedness  of  a  program,  involves  mostly  apply¬ 
ing  the  appropriate  inference  rules,  finding  intermediate  assertions 
like  a',  and  proving  the  logical  implications. 

The  soundness  of  these  inference  rules  is  established  with  respect  to 
the  operational  semantics  following  the  syntactic  approach  of  prov¬ 
ing  type  soundness  [44].  The  soundness  theorem  below  guarantees 
that  given  a  well-formed  program,  the  current  instruction  sequence 
will  be  able  to  execute  without  getting  “stuck”  (normal  type-safety); 
in  addition,  whenever  we  jump  to  a  code  block,  the  specified  asser¬ 
tion  of  that  code  block  (which  is  an  arbitrary  state  predicate  given 
by  the  user)  will  hold. 

Theorem  1  (CAP  Soundness)  IfT*!-  {a}(C,S,I),  then  for  all 
natural  number  n,  there  exists  a  program  P  such  that 
(C,S,I)i — and 

•  if  (C,S,I)i — >*(C,S',jd  f),  then  T-)! )  S'; 

•  if  (C,S,I)i — >*(C,(H,R),(bgtri,rf,f))  andR(rj)  >  R(r,), 
then  *F(f)  (H,R). 


Interested  readers  are  referred  to  the  previous  work  [46,  47]  for 
a  complete  modeling  of  CAP  and  a  certified  malloc/free  library 
whose  correctness  criterion  involves  more  than  type-safety. 


2.2  Invariance  Proof 

The  code  heap  type  of  CAP  allows  the  specification  of  certain  pro¬ 
gram  properties  in  addition  to  type  safety.  However,  it  appears 
insufficient  in  modeling  general  safety  properties,  which  typically 
disallow  undesired  things  from  happening  at  any  program  points. 
Directly  accommodating  such  a  property  in  CAP  would  require  in¬ 
spection  of  preconditions  at  all  program  points,  resulting  in  an  un¬ 
wieldy  specification. 


T*  h  {  a}  P  (well-formed  program) 

*P  h  C  (well-formed  code  heap) 

T*  h  {  a}  I  (well-formed  instruction  sequence) 

The  intuition  of  well-formed  instruction  sequence,  for  example,  is 
that  if  the  instruction  sequence  I  starts  execution  in  a  machine  state 
which  satisfies  the  assertion  a,  then  executing  I  is  safe  with  respect 
to  the  specification  T*. 

In  Figure  3,  we  give  some  sample  inference  rules  which  the  pro¬ 
grammers  use  to  prove  the  safety  of  their  programs.  A  program 
is  well-formed  (rule  PROG)  under  assertion  a  if  both  the  code  heap 
and  the  instruction  sequence  are  well-formed,  and  the  machine  state 
satisfies  the  assertion  a.  A  code  heap  is  well-formed  (rule  CODE¬ 
HEAP)  if  every  code  block  is  well-formed  under  the  associated  as¬ 
sertion.  A  direct  jump  is  safe  (rule  JD)  if  the  current  assertion  is 
no  weaker  than  the  assertion  of  the  target  code  block  as  specified 


Fortunately,  many  methods  have  been  proposed  for  proving  safety 
(invariance)  properties  for  both  sequential  and  concurrent  pro¬ 
grams  [12,  17,  33,  25,  24].  As  observed  by  Lamport  [24],  “all  of 
these  methods  are  essentially  the  same — when  applied  to  the  same 
program,  they  involve  the  same  proof,  though  perhaps  in  different 
orders  and  with  different  notation.”  In  particular,  the  execution  of 
a  program  can  be  viewed  as  transitions  of  states,  and  a  general  in¬ 
variance  proof  of  a  program  satisfying  a  safety  property  P  reduces 
to  finding  an  invariant  I  satisfying  three  conditions: 

1 .  The  initial  state  of  the  program  satisfies  7; 

2.  /  implies  P\ 

3.  If  a  state  satisfies  7,  then  the  next  state  satisfies  7. 

Interestingly,  this  “invariance  proof”  technique  also  characterizes 
certain  principles  found  in  the  syntactic  approach  to  type  sound¬ 
ness  [44],  as  engaged  by  many  modem  type  systems.  In  fact,  the  re- 


(1) 

/i  :  moviri,! 

(2) 

(3) 

yield 

(4) 

St  r2(0),ri 

(5) 

jd/2 

(6) 

/2  :  movi  ri,2 

(7) 

St  r2(l),ri 

(8) 

yield 

(9) 

(10) 

jd/3 

Figure  4.  Example:  Non-preemptive  thread  control. 


semblance  is  clear  once  we  describe  the  type-safety  proofs  of  these 
systems  as  follows: 

1.  The  program  is  initially  well-typed; 

2.  If  a  program  is  well-typed,  then  it  makes  a  step  (usually  re¬ 
ferred  to  as  a  lemma  of  “progress”); 

3.  If  a  program  is  well- typed,  then  it  is  also  well-typed  af¬ 
ter  making  a  step  (usually  referred  to  as  a  lemma  of  “type- 
preservation”). 

It  is  not  difficult  to  observe  that  the  syntactic  approach  to  type 
soundness  is  in  essence  a  special  application  of  the  invariance  proof 
where  the  invariant  I  is  well-typedness  of  the  program  and  the 
safety  property  P  is  type-safety  {i.e.,  non-stuckness).  Since  the 
progress  and  preservation  lemmas  of  such  type  systems  are  proved 
once  and  for  all,  all  that  remains  when  writing  a  program  is  to  verify 
the  (initial)  well-typedness  by  typing  rules. 

The  story  of  CAP  is  similar — the  invariant  1  is  the  well-formedness 
of  the  program  and  the  safety  property  P  is  type-safety  and  satisfac¬ 
tion  of  the  code  heap  specification.  The  problem  we  encountered 
applying  CAP  directly  to  general  safety  properties  now  becomes 
apparent:  type-safety  and  satisfaction  of  the  code  heap  specifica¬ 
tion  is  not  sufficient  in  modeling  arbitrary  safety  properties.  On  the 
bright  side,  a  solution  becomes  also  apparent:  it  suffices  to  enhance 
the  judgment  of  well-formed  programs  so  that  it  implies  the  validity 
of  a  user  specified  predicate  Im  (referred  to  as  a  “global  invariant” 
in  the  remainder  of  this  paper),  which  in  turn  implies  a  safety  prop¬ 
erty  of  concern.  Such  a  CAP-like  language  maintains  the  flavor  of 
a  type  system,  but  the  “typing  rules”  are  practically  “proof  rules”  of 
a  logic  system. 

2.3  Assume-Guarantee 

A  last  piece  of  the  puzzle  is  a  compositional  method  for  reason¬ 
ing  about  the  interaction  between  threads.  Since  Francez  and 
Pnueli  [13]  developed  the  first  method  for  reasoning  composi- 
tionally  about  concurrency,  various  methods  have  been  proposed, 
the  most  representative  ones  of  which  are  assumption-commitment 
invented  by  Misra  and  Chandy  [27]  for  message-passing  sys¬ 
tems  and  rely-guarantee  by  Jones  [23]  for  shared-memory  pro¬ 
grams.  These  two  methods  have  thereupon  been  carefully  stud¬ 
ied  [32,  36,  40,  41,  1,  45,  2,  5,  16,  11]  and  often  referred  to  as 
assume- guarantee. 

Under  this  assume-guarantee  paradigm,  every  thread  (or  process) 
is  often  associated  with  a  pair  (A,G)  consisting  of  a  guarantee  G 
that  the  thread  will  satisfy  provided  the  environment  satisfies  the 
assumption  A.  Under  the  shared-memory  model,  the  assumption  A 


(Prog)  P  ::=  (S, Cl, C2,Ii,l2,i)  where  i  G  {1,2} 

(State)  S  ::=  (M,R) 

(Mem)  M  ::={l'^w}* 

(RegFile)  R  ::={r'^w}* 

(Register)  r  ::= 

(Labels)  f ,  1  ::=  n  (nat  nums) 

(WordVal)  w  ::=  n  (nat  nums) 

(CdHeap)  C  ::={f'^I}* 

(InstrSeq)  I  ::=  c;I  |  ]d  f 

(Comm)  c  ::=  yield  I  add  r,i,ri,rf  I  sub  r^,rs,r, 

I  movi  rj,w  I  bgt  rj,r,,f  |  be  ri,ri,f 

I  Id  i-rf,ri(w)  I  strj(w),ri 

Figure  5.  Syntax  of  CCAP. 

of  a  thread  describes  what  atomic  transitions  may  be  performed  by 
other  threads,  and  the  guarantee  G  of  a  thread  must  hold  on  every 
atomic  transition  performed  by  the  thread  itself.  They  are  typically 
modeled  as  predicates  on  a  pair  of  states,  which  are  often  called 
actions.  Reasoning  about  a  concurrent  program  then  reduces  to 
reasoning  about  each  thread  separately,  provided  that  the  guarantee 
of  each  thread  be  no  weaker  than  the  assumption  of  every  other 
thread. 

We  apply  this  approach  at  an  assembly  level,  using  assumptions  and 
guarantees  to  characterize  the  interaction  between  threads.  In  Sec¬ 
tion  3,  our  abstract  machine  adopts  a  non-preemptive  thread  model, 
in  which  threads  yield  control  voluntarily  with  a  command  yield. 
An  atomic  transition  in  a  preemptive  setting  then  corresponds  to  a 
sequence  of  commands  between  two  yield  in  our  setting.  Figure  4, 
for  example,  shows  two  code  blocks  that  belong  to  the  same  thread; 
the  state  transition  between  the  two  yield  at  lines  (3)  and  (8)  must 
satisfy  the  guarantee  of  the  current  thread,  and  the  potential  state 
transition  at  either  yield,  caused  by  other  threads,  is  expected  to  sat¬ 
isfy  the  assumption. 

A  difficulty  in  modeling  concurrency  in  such  a  setting  is  that  one 
has  to  “look  inside”  an  atomic  operation.  It  is  different  from  mod¬ 
eling  an  atomic  operation  as  a  whole,  as  is  the  case  of  some  previous 
work  on  concurrency  verification,  where  the  state  transition  caused 
is  immediately  visible  when  analyzing  the  atomic  operation.  When 
an  atomic  operation  is  made  up  of  a  sequence  of  commands,  its  ef¬ 
fect  can  not  be  completely  captured  until  reaching  the  end.  For  ex¬ 
ample,  in  Figure  4,  the  state  change  caused  by  the  st  at  line  (4)  need 
not  immediately  satisfy  the  guarantee;  instead,  it  may  rely  on  its  fol¬ 
lowing  commands  (i.e.,  lines  (6)  and  (7))  to  complete  an  adequate 
state  transition.  Hence  when  verifying  the  safety  of  a  command  us¬ 
ing  CAP-style  inference  rules,  it  is  insufficient  to  simply  check  the 
guarantee  against  the  state  change  cause  by  that  command.  In  our 
modeling,  we  introduce  a  “local  guarantee”  g  for  every  program 
point  to  capture  further  state  changes  that  must  be  made  by  the  fol¬ 
lowing  commands  before  it  is  safe  for  the  current  thread  to  yield 
control. 

Such  a  non-preemptive  setting  helps  to  separate  thread  interaction 
from  other  orthogonal  issues  of  assembly  verification.  For  instance, 
from  the  example  of  Figure  4,  it  is  apparent  that  the  thread  inter¬ 
action  using  yield  is  orthogonal  from  the  handling  of  control  flow 
transfer  (e.g.,  direct  jump  jd  or  indirect  jump  jmp).  This  also  pro¬ 
vides  insights  on  the  verification  of  preemptive  threads,  because  a 
preemptive  model  can  be  considered  as  a  special  case  of  the  non- 
preemptive  model  in  which  explicit  yielding  is  used  at  all  program 
points. 


1  ((M,IR),Ci,C2,IIi,Il27 1) ' — >  P  where 

ifli  = 

then  P  = 

jdf 

((M,R),6i,62,I',l2, 1)  where  61(f)  =  I' 

yield;!' 

((M,R),6i,62,I',l2,i)  where  i  e  {1,2} 

bgt  ri,rf,f;r 

((M,R),6i,62,I',l2, 1)  when  R(rj)  <  R(r();  and 
((M,R),6i,62,I",l2, 1)  when  R(rj)  >  R(r()  where  61(f)  =  I" 

be 

((M,R),6i,62,I',l2, 1)  when  R(rj)  7^  R(ri);  and 
((M,R),6i,62,I",l2, 1)  when  R(rj)  =  R(ri)  where  61(f)  =  I" 

c;I'  for  remaining  cases  of  c 

(Next(c,(M,R)),6i,62,I',l2, 1) 

1  ( (M,R), 6 1,62,11,12, 2)  1 — >  P  defined  similarly 

Figure  6.  Operational  semantics  of  CCAP. 


if  c  = 

then  Next(c,  (M,R))  = 

add  r4,rs,r, 

(M,R{rrf  R(rs)  -|-R(r,)}) 

SUbr^,rj,r, 

(M,R{rrf  R(rs)  -R(r,)|) 

movi  r^,w 

(M,R{r^'^w|) 

Id  r^,ri(w) 

(M,R{r^  M(R(rj)  +w)}) 
where  (R(rj)  -fw)  e  dom(M) 

St  r^(w),ri 

(M{R(r^)  -fw'^  R(rj)|,R) 
where  (R(r^)  +w)  e  dom(M) 

Figure  7.  Auxiliary  state  update  macro. 


(ProgSpec)  <F::=  (/nv,*Fi,'F2,Ai,A2, 61,62) 
{CdHpSpec)  'F  ::=  {f (p,g)}* 

(ThrdSpec)  ©  ::=  (/nv,*F,  A,6) 


{Invariant) 

{Assertion) 

{Assumption) 

{Guarantee) 


Inv  e  State  ^Prop 
p  e  State— *Prop 
A  G  State  ^State^Prop 
6,g  e  State— *State-^Prop 


Figure  8.  Verification  constructs  of  CCAP. 


3  CCAP 

CAP  supports  mechanical  verification  on  sequential  assembly  code; 
invariance  proof  can  be  applied  to  reason  about  general  safety 
properties;  and  assume-guarantee  allows  the  decomposition  of  a 
concurrent  program  into  smaller  pieces  which  in  turn  can  be  rea¬ 
soned  about  sequentially.  The  remaining  task  is  to  accommodate 
these  techniques  in  a  single  language  CCAP.  In  particular,  assume- 
guarantee  must  be  adapted  to  work  for  non-preemptive  assembly 
code,  as  briefly  explained  in  the  previous  section. 

In  this  section,  we  present  CCAP  based  on  an  abstract  machine  that 
supports  the  concurrent  execution  of  two  threads  using  a  shared 
memory.  A  generalized  version  supporting  more  threads  is  given 
in  Appendix  A. 

3.1  Abstract  Machine 

The  abstract  machine  is  a  straightforward  extension  from  CAP  (see 
Figure  5  for  the  syntax).  A  program  P  consists  of  a  shared  state 
component  S  made  up  of  a  memory  M  and  a  register  file  R,  two 
code  heaps  6  (one  for  each  thread),  two  current  instruction  se¬ 
quences  I  (one  for  each  thread),  and  an  indicator  i  indicating  the 
current  thread. 

Threads  may  interact  using  the  shared  memory,  and  yield  control 
(yield)  voluntarily.  Only  a  small  set  of  commands  are  modeled 
for  simplicity,  but  extensions  are  straightforward.  Note  that  there 
is  no  need  for  instructions  such  as  “test-and-set”  because  of  non¬ 
preemption. 

The  operational  semantics  is  defined  in  Figures  6  and  7.  Figure  7 
defines  a  “next  state”  macro  relation  detailing  the  effect  of  some 
commands  on  the  machine  state.  For  memory  access  or  update 
commands  (Id,  st),  the  macro  is  defined  only  if  the  side  conditions 
are  met.  In  Figure  6,  we  only  show  the  cases  where  thread  1  is  the 
current  thread;  the  other  cases  are  similar.  At  a  yield  command,  the 
machine  picks  a  thread  non-deterministically  without  affecting  the 


state.  Control  flow  commands  (jd,  bgt  and  be)  do  not  affect  the  state 
either.  Implicit  from  these  two  figures  is  that  the  machine  gets  stuck 
when  executing  a  memory  access  or  update  but  the  side  condition 
as  specified  by  the  macro  is  not  met. 

3.2  Inference  Rules 

Verification  constructs  of  CCAP  are  introduced  in  Figure  8.  A  pro¬ 
gram  specification  <I>  consists  of  a  global  invariant  {Inv),  assump¬ 
tions  (A)  and  guarantees  (6),  and  code  heap  specifications  (*?).  A 
programmer  must  find  a  global  invariant  Inv  for  the  program;  Inv 
should  be  no  weaker  than  the  safety  property  of  interest  and  hold 
throughout  the  execution  of  the  program.  A  programmer  must  also 
find  for  each  thread  a  guarantee  6  and  an  assumption  A  describing 
allowed  atomic  state  transitions  of  the  thread  and  its  environment 
respectively. 

Every  thread  also  has  its  own  code  heap  specification  *P.  As  is  the 
case  of  CAP,  T*  is  a  mapping  from  code  labels  to  preconditions. 
What’s  different  now  is  that  a  precondition  in  CCAP  contains  not 
only  an  assertion  p  describing  valid  states,  but  also  a  guarantee  g 
describing  valid  state  transitions — it  is  safe  for  the  current  thread 
to  yield  control  only  after  making  a  state  transition  allowed  by  g. 
We  call  g  a  “local  guarantee”  to  distinguish  it  from  6.  To  prove 
the  safety  of  a  program,  the  programmer  needs  to  find  appropriate 
preconditions  for  all  program  points,  and  apply  the  inference  rules 
to  be  introduced  later. 

CCAP’s  reasoning  is  thread-modular:  the  verification  of  a  concur¬ 
rent  program  can  be  decomposed  into  the  verification  of  its  com¬ 
ponent  threads,  and  each  thread  is  reasoned  about  separately  with 
respect  to  its  own  thread  specification.  We  use  0  to  denote  such  a 
thread  specification,  which  consists  of  the  global  invariant  Inv,  and 
the  code  heap  specification  *P,  assumption  A  and  guarantee  6  of 
the  thread.  The  program  specification  can  then  be  considered  as  a 
union  of  the  thread  specification  of  every  component  thread. 

We  use  the  following  judgment  forms  to  define  the  inference  rules: 


‘I>;  (pi  ,P2,g)  h  P  {well-formed program) 

0  h  C  {well-formed  code  heap) 

(P)  g)  1“  I  {well-formed  instr.  seq.) 

These  judgment  forms  bear  much  resemblance  to  those  of  CAP, 
noting  that  preconditions  have  evolved  to  include  local  guarantees. 
When  verifying  for  a  well-formed  program,  an  extra  assertion  is 
used  to  describe  a  state  expected  by  the  idling  thread;  however,  no 
extra  local  guarantee  is  needed. 

Well-formed  program  There  are  two  rules  for  checking  the 
well-formedness  of  a  program.  Rule  PROGl  is  used  when  thread 
1  is  the  current  thread,  and  Rule  PROG2  is  used  when  thread  2  is 
the  current  thread. 

<h=(/Mv,'Pi,'P2,Ai,A2,Gi,G2) 

(/MV  A  Pi  S)  VS",  (g  S  S")  D  (P2  S") 

VS'.  VS".  (/MVAP2  S')  D  (A2  s'  S")  d  (p2  S") 

(/mv,'Pi,Ai,Gi)  h  Cl  (/Mv,*Pi,Ai,Gi);(pi,g)  hli 

(/mv,'P2,  A2,G2)  V  C2  (/mv,*P2,  A2,G2);(p2,G2)  V  I2 
‘5;(Pi,P2,g)  1“  (S,Ci,C2,Il,l2,l) 

(PROGl) 

<h=  (/mv,'Pi,'P2,Ai,A2,Gi,G2) 

(/MV  A P2  S)  VS",  (g  S  S")  D  (Pi  S") 

VS'.  VS".  (/MV  A  Pi  S')  D  (Ai  S'  S")  D  (pi  S") 

(/mv,T'2,A2,G2)  V  C2  (/mv,*P2,  A2,G2);(p2,g)  V  I2 
(/mv,*?!, Ai,Gi)  h  Cl  (/mv,*Pi,Ai,Gi);(pi,Gi)  hli 

4’;(pi,P2>g)  1“  (s,Ci,C2,ii,i2,2) 

(prog2) 

Since  these  two  rules  are  symmetrical,  we  only  explain 
Rule  PROGl,  where  thread  1  is  the  current  thread.  In  this  rule, 
the  well-formedness  of  a  program  is  determined  with  respect  to  not 
only  the  program  specification  <I>,  but  also  an  assertion  pi  describ¬ 
ing  the  current  state,  an  assertion  p2  describing  the  state  in  which 
thread  2  may  take  control,  and  a  relation  g  describing  the  discrep¬ 
ancy  between  these  two  states. 


this  requirement  in  the  inference  rules,  but  will  use  it  as  a  premise 
of  a  soundness  lemma. 


Well-formed  code  heap 


0=  (/mv,'P,A,G) 

>P  =  {fj'x..^(p^.,g^.)}^e{l...«} 


Q;(PAgj)  Vye{i---w} 

01- 


(CODEHEAP) 


A  code  heap  is  well-formed  if  every  code  block  is  well-formed  un¬ 
der  the  associated  precondition.  Note  that  after  the  decomposition 
performed  by  Rules  PROGl  and  PROG2,  every  thread  is  verified 
separately  under  its  own  thread  specification. 


Well-formed  instruction  sequence 

0  =  (/mv,'I',A,G) 
VS.(/MvApS)D(gSS) 

VS.  VS'.  (/MvAp  S)  D  (A  S  S')  D  (p  S') 
0;  (p,G)l-I 

0;(p,g)  h  yield;I 


(YIELD) 


Rule  YIELD  is  used  to  verify  an  instruction  sequence  starting  with 
yield.  It  is  safe  to  yield  control  under  a  state  S  only  if  required  state 
transitions  are  complete,  i.e.,  an  identity  transition  from  S  satisfies 
the  local  guarantee  g.  Furthermore,  the  assertion  p  must  preserve 
itself  under  transitions  allowed  by  the  assumption  A,  indicating  that 
it  is  safe  to  execute  any  number  of  atomic  operations  by  the  other 
thread.  Lastly,  one  must  verify  the  remainder  instruction  sequence 
I  with  the  local  guarantee  reset  to  G. 


0  =  (/mv,T',A,G) 

VS.  (/mv  Ap  S)  D  (/MvAp'  Next(c,S)) 

VS.  VS'.  (/MV  Ap  S)  D  (g'  Next(c,S)  S')  D  (g  S  S') 
0;(p',g')l-I  c  e  {add.sub,  movi} 


0;(p,g)  1“ 


(SIMPL) 


The  premises  of  Rule  PROGl  may  appear  complex,  but  are  rather 
intuitive.  Line  1  gives  us  the  components  of  <I>.  Lines  2  requires  that 
both  the  global  invariant  /mv  and  the  current  assertion  pj  must  hold 
on  the  current  state;  it  also  restricts  the  assertion  P2  of  thread  2  and 
the  current  guarantee  g  of  thread  1 :  if  some  operations  satisfying  g 
is  performed  on  the  current  state,  then  the  result  state  satisfies  P2. 
This  indicates  that  it  is  sufficient  to  refer  to  g  for  the  expectation  of 
thread  2  when  checking  thread  1 . 


Rule  SIMPL  covers  the  verification  of  instruction  sequences  starting 
with  a  simple  command  such  as  add,  sub  or  movi.  In  these  cases, 
one  must  find  an  intermediate  precondition  (p',  g')  under  which  the 
tail  instruction  sequence  I  is  well-formed.  Moreover,  the  global 
invariant  Inv  and  the  intermediate  assertion  p'  must  hold  on  the  up¬ 
dated  machine  state,  and  the  intermediate  guarantee  g'  applied  to 
the  updated  machine  state  must  be  no  weaker  than  the  current  guar¬ 
antee  g  applied  to  the  current  state. 


When  thread  1  is  executing,  thread  2  should  be  in  a  “safe  state” 
whose  properties  described  by  P2  will  not  be  disturbed  by  allowed 
(assumed)  transitions  of  thread  1.  Hence  line  3  restricts  the  as¬ 
sertion  P2  to  preserve  itself  under  state  transitions  that  satisfy  the 
assumption  A2.  Note  that  “D”  is  right  associative,  i.e.,  aDfiDc  is 
interpreted  as  a  D  (fi  D  c) . 

The  last  two  lines  decompose  the  verification  task  into  two  parts, 
each  performed  independently  for  a  single  thread  based  on  the  cor¬ 
responding  thread  specification.  For  thread  1  (line  4),  the  code  heap 
must  be  well-formed,  and  the  current  instruction  sequence  must  be 
well-formed  under  the  current  precondition.  The  requirements  for 
thread  2  is  similar  (line  5),  except  that  the  guarantee  G2  is  used  in 
the  precondition  of  thread  2,  indicating  necessary  state  transitions 
before  thread  2  may  yield. 

Another  requirement  is  that  the  assumptions  and  the  guarantees  be 
compatible,  i.e.,  Gi  D  A2  and  G2  D  Ai.  Noting  that  these  relations 
are  constants  and  concern  only  the  specification,  we  do  not  include 


Consider  a  sequence  of  states  between  two  “safe  points” 

(i.e.,  between  two  yield  commands).  Suppose  we  have  a  sequence 
of  guarantees  gj . . .  g„  such  that: 

(g2  §2  S«)  A  (gl  Si  S„);  (LOCAL-GUAR) 

(g3  S3S„)D(g2  S2S„); 

(Sn-1  S«— 1  Sn)  D  (gn-2  S«— 2  S«); 

(Sn  Sn)  D  (g„_i  S„_l  S„). 

From  these  we  know  that  the  state  transition  from  Si  to  S„  satisfies 
the  original  guarantee  gi  if  only  (g„  S„  S„),  which  will  be  estab¬ 
lished  at  the  yield  command. 

0=  (/mv,'I',A,G) 

VM.VR.  (/mv  Ap  (M,R))  D  ((R(rj)  -f  w)  G  dom(M)) 

VS.  (/MvAp  S)  D  (/mv  Ap'  Next(c,S)) 

VS.  VS'.  (/MvAp  S)  D  (g'  Next(c,S)  S')  D  (g  S  S') 

0;(p',g')|-I  c  =  ldrrf,rs(w) 

0;(p,g)Vc;I  '  ^ 


0  =  {Inv,'i',A,G) 

VM.VM.  {InvAp  (M,R))  D  ((R(rj)  +w)  e  dom(M)) 

VS.  {InvAp  S)  D  (/nvAp'  Next(c,S)) 

VS.  VS',  (/nv  Ap  S)  D  (g'  Next(c,S)  S')  D  (g  S  S') 
0;(p',g')|-I  c  =  strj(w),rs 

0;(p,g)^c;I  ^  ' 

Verifying  memory  access  or  update  with  Rules  LD  or  ST  is  in  spirit 
similar  to  verifying  simple  commands,  except  one  must  also  estab¬ 
lish  the  side  condition  as  specified  by  the  macro  Next. 

0  =  (/«v,'i',A,G)  'i'(f)  =  (p',g') 

VS.(/nvApS)D(p'  S) 

VS.  VS'.  (Inv  A p  S)  D  fg'  S  S')  D  (g  S  S') 

0;(p,g)^jdf  ^  ^ 

Direct  jump  is  easily  verified  by  fetching  the  precondition  from  the 
code  heap  specification,  as  shown  in  Rule  JD.  There  is  no  need  to 
re-establish  the  global  invariant  Inv  explicitly,  because  the  machine 
state  remains  the  same. 

0  =  (/nv,'i',A,G)  ‘R(f)  =  (p',g') 

VM.VR.(R(rj)  >R(r,))D(/nvAp  (M,R))d(p'  (M,R)) 
VM.VR.VS'.(R(rj)  >R(r,))D(/nvAp  (M,R)) 

D(g'  (M,R)  S')D(g  (M,R)  S') 
VM.VR.(R(rj)  <R(r,))D(/MvAp  (M,R))d(p"  (M,R)) 
VM.VR.VS'.(R(rj)  <R(r,))D(/nvAp  (M,R)) 

D(g"  (M,R)  S')D(g  (M,R)  S') 

Q;(p",g")n _ 

0;(p.g)  1“  bgtrj,r,,f;I 


0=(/nv,'i',A,G)  ‘R(f)  =  (p',g') 

VM.VR.(R(rj)  =R(r,))D(/nvAp  (M,R))d(p'  (M,R)) 
VM.VR.VS'.(R(rj)  =R(r,))D(/nvAp  (M,R)) 

D(g'  (M,R)  S')D(g  (M,R)  S') 
VM.VR.(R(rj)  7^R(r,))D(/nvAp  (M,R))d(p"  (M,R)) 
VM.VR.VS'.(R(rj)  7^R(r,))D(/nvAp  (M,R)) 

D(g"  (M,R)  S')D(g  (M,R)  S') 

e;(p",g")H _ 

0;(p,g)  1“  be 

(BE) 

Lastly,  a  conditional  command  is  safe  if  both  branches  can  be  veri¬ 
fied,  hence  Rule  BGT  or  BE  can  be  understood  as  a  combination  of 
Rules  JD  and  SIMPL,  noting  that  the  comparison  result  can  be  used 
in  verifying  the  branches. 


3.3  Soundness 


The  soundness  of  these  inference  rules  with  respect  to  the  opera¬ 
tional  semantics  of  the  machine  is  established  following  the  syn¬ 
tactic  approach  of  proving  type  soundness.  From  the  “progress” 
and  “preservation”  lemmas  (proved  by  induction  on  I;  see  the  im¬ 
plementation  for  detailed  Coq  proofs  [43]),  we  can  guarantee  that 
given  a  well-formed  program  under  compatible  assumptions  and 
guarantees,  the  current  instruction  sequence  will  be  able  to  execute 
without  getting  “stuck.”  Furthermore,  any  safety  property  derivable 
from  the  global  invariant  will  hold  throughout  the  execution. 

Lemma  1  (Code  Lookup)  If  F  C  and  *F(f)  =  (p,g), 

then  there  exists  I  such  that  C(f )  =1. 

Proof  sketch:  By  definition  of  well-formed  code  heap.  □ 


Lemma  2  (Progress)  <I>  =  (/nv,'Pi,*P2,  Ai,  A2,Gi,G2).  If 
‘J’;(PliP2>g)  ^  (S,Ci,C2,Ii,l2,i)  where  i  e  {1,2},  then  (/«vS) 
and  there  exists  a  program  P  such  that  (S,Ci  ,C2,Ii,l2,i) ' — >  P- 


Proof  sketch:  By  induction  on  the  structure  of  I;.  (/nv  S)  holds  by 
definition  of  well-formed  program.  In  the  cases  where  I;  starts 
with  add,  sub,  movi  or  yield,  the  program  can  always  make  a  step 
by  the  definition  of  the  operational  semantics.  In  the  cases  where  I; 
starts  with  Id  or  st,  the  side  conditions  for  making  a  step,  as  defined 
by  the  operational  semantics,  are  established  by  the  corresponding 
inference  rules.  In  the  cases  where  1;  starts  with  bgt  or  be,  or 
where  I;  is  jd,  the  operational  semantics  may  fetch  a  code  block 
from  the  code  heap;  such  a  code  block  exists  by  Lemma  1 .  □ 

Lemma  3  (Code  Well-formedness)  If  0  =  (-jT*,  _),  0  F  C, 

*P(f )  =  (p,g)  and  C(f)  =  I,  then  0;  (p,g)  F  I. 

Proof  sketch:  By  definition  of  well-formed  code  heap.  □ 

Lemma  4  (Preservation)  ‘F  =  (Inv,  *P  i ,  ^*2 ,  A  i ,  A2 ,  G  i ,  G2 ) . 
Suppose  VS'.  VS".  (Gi  S'  S")  D  (A2  S'  S")  and 
VS'.  VS".  (G2  S'  S")  D  (Ai  S'  S"). 

If  <F;(pi,P2,g)  F  (S,Ci,C2,Ii,l2,t)  where  t  e  {1,2}, 
and  (S,Ci,C2,Ii,l2,0  ' — >  P, 

then  there  exists  p} ,  P2  and  g'  such  that  <I>;  (p) ,  P2 ,  g')  F  P. 

Proof  sketch:  By  induction  on  the  structure  of  I,.  We  must  estab¬ 
lish  the  premises  (lines  2-5)  of  Rule  PROGl  or  PROG2. 

The  first  half  of  line  2  is  easily  established:  for  any  command  that 
updates  the  machine  state,  its  corresponding  inference  rule  dictates 
that  the  global  invariant  and  the  postcondition  hold  on  the  updated 
machine  state.  The  second  half  of  line  2  also  follows  naturally,  be¬ 
cause  the  inference  rules  yield  a  sequence  of  “strengthening”  local 
guarantees,  as  illustrated  by  the  equations  LOCAL-GUAR. 

Unless  I;  starts  with  yield,  line  3  is  trivially  preserved  because  the 
precondition  of  the  idling  thread  remains  unchanged;  in  the  case 
where  I,-  starts  with  yield,  the  current  thread  may  become  the  idling 
thread,  and  line  3  follows  from  a  premise  of  Rule  YIELD. 

The  first  half  of  lines  4  and  5  (well-formed  code  heaps)  is  not  af¬ 
fected  by  a  program  step,  hence  it  is  trivially  preserved.  For  the 
second  half  of  lines  4  and  5  (well-formed  instruction  sequences), 
in  the  cases  where  I;  starts  with  add,  sub,  movI,  yield,  Id  or  st,  the 
well-formedness  of  the  instruction  sequence  in  the  next  state  can 
be  directly  derived  from  the  corresponding  inference  rules;  in  the 
cases  where  I;  starts  with  bgt  or  be,  or  is  jd,  we  apply  Lemma  3.  □ 

4  Examples 

CCAP  is  a  realization  of  established  verification  techniques  at  the 
assembly  level.  The  expressiveness  of  these  techniques  and  their 
application  to  high-level  programs  are  well-known.  In  this  section, 
we  give  3  simple  examples  to  demonstrate  the  mechanized  veri¬ 
fication  of  interesting  safety  properties  for  assembly  code  and,  in 
particular,  illustrate  the  usage  of  local  guarantees  (g)  as  part  of  the 
preconditions. 

4.1  Mutual  Exclusion 

Dekker’s  algorithm  [10]  is  the  first  solution  to  mutual  exclusion 
problem  for  the  two-process  case.  Flanagan  et  al.  [11]  have  given 
a  modeling  under  the  assume-guarantee  paradigm  for  a  high-level 
parallel  language  of  atomic  operations.  In  this  section,  we  show  that 
the  subtle  synchronization  used  in  Dekker’s  algorithm  can  be  rea¬ 
soned  about  as  easily  in  CCAP,  where  atomic  operations  are  com¬ 
posed  of  sequences  of  instructions. 


The  algorithm  is  revised  using  4  boolean  variables  [11]  (Figure  9). 
It  is  easy  to  observe  that  variable  csi  is  true  if  thread  i  is  in  its  crit- 


Variables: 

boolean  ai,a2,csi,cs2; 


Initially: 

-icsi  A  -1CS2 


Variables: 

nat  forki,fork2; 


Initially: 

f  orki  =  0  A  f  ork2  =  0 


Thread  1 : 

while  (true){ 
ai  :=  true; 
csi  :=  -'a2; 
if  (csi)  { 

//  critical  sec. 
csi  :=  false; 

} 

ai  :=  false; 

} 


Thread2  : 

while  (true){ 
a2  :=  true; 

CS2  :=  ^ai; 
if  (CS2)  { 

/ /  critical  sec. 
CS2  :=  false; 

} 

a2  :=  false; 

} 


Figure  9.  Dekker’s  mutual  exclusion  algorithm. 


Thread  1: 

while  (true){ 

acquire(forki,  1); 
acquire  (fork2, 1); 
//  eat 

release  (fork2); 
release  (forki); 

//  think 

} 


Thread2  : 

while  (true){ 

acquire(f  orki,2); 
acquire(f  ork2, 2); 
/ /  eat 

release(f  ork2); 
release  (forki); 

/ /  think 

} 


Figure  11.  Dining  philosophers  algorithm. 


Inv  =  M(csi),M(cs2),M(ai),M(a2)  £  {0, 1} 
A-'(M(csi)  AM(cs2)) 

A(M(csi)  D  M(ai))  A  (M(cs2)  D  M(a2)) 
Ai,G2  =  (M(ai)  =M'(ai))A(M(csi)  =M'(csi)) 
A2,Gi  =  (M(a2)  =  M'(a2))  A  (M(cs2)  =  M'(cs2)) 

Initial  M  =  {csi  0,  cs2  0,  ai  a2  _} 

Initial  thread:  i  where  i  G  {1,2} 

Initial  instruction  sequences:  I;  =  jd  loopi 

Initial  precondition  triple:  (pi,p2,g)  =  (True, True, G,) 


loopi  :  — {(True,Gi)} 
yield 

movi  ri,ai 
movi  r2, 1 
stri(0),r2 
-{(H(ai)  =  l,Gi)} 
yield 

movi  ri,csi 
movi  r2, 1 
movi  r3,a2 
Id  r4,r3(0) 
SUbr5,r2,r4 
Stri(0),r5 
— {(True,Gi)} 
yield 

movi  ri,csi 

Id  r2,ri(0) 

movi  r3,0 

bgt  r2,r3,cjeci 

-{(H(csi)=0,Gi)} 

yield 

jd  resell 


cseci  :  — {(True,Gi)} 
yield 

-{(True,Gi)} 
movi  ri,csi 
-{(R(ri)  =  csi,Gi)} 
movi  r2,0 
-{(R(ri)  =  csiA 
]R(r2)  =  0,Gi)} 
Stri(0),r2 
-{(H(csi)=0,Gi)} 
yield 

-{(H(csi)=0,Gi)} 
jd  resell 

resell  '■  — {(H(csi)  =  0,Gi)} 
yield 

movi  ri,ai 
movi  r2,0 
Stri(0),r2 
-{(True,Gi)} 
yield 
jd  loopi 


Figure  10.  CCAP  implementation  for  Dekker’s  algorithm. 


ical  section;  hence  the  mutual  exclusion  property  of  this  algorithm 
can  be  expressed  as  -'(csi  A  CS2). 

To  decompose  the  verification  problem  into  two  sequen¬ 
tial  ones,  thread  i  makes  the  assumption  that  the  other 
thread  not  modify  variables  ai  and  csi.  Furthermore,  the 
mutual  exclusion  property  is  strengthened  to  the  invariant 
-'(csi  A  CS2)  A(csiDai)A(cs2Da2). 

Some  key  components  of  a  corresponding  CCAP  implementation 
of  the  algorithm  are  shown  in  Figure  10.  Only  the  code  of  thread 
1  is  given,  since  that  of  thread  2  is  similar.  Yielding  is  inserted  at 
all  the  intervals  of  the  atomic  operations  of  the  original  program. 


The  code  heap  specification  is  separated  and  given  as  preconditions 
(surrounded  by  —  {})  at  the  beginning  of  each  code  block  for  ease 
of  reading.  Extra  preconditions  are  spread  throughout  the  code  as 
an  outline  of  the  proof — the  inference  rules  can  be  easily  applied 
once  preconditions  are  given  at  all  program  points. 

For  expository  convenience,  we  use  variable  names  as  short-hands 
for  memory  locations.  The  boolean  values  false  and  true  are 
encoded  using  0  and  1  respectively.  We  also  omit  the  variable  bind¬ 
ings  from  the  predicates.  To  be  exact,  a  “AS.”  is  omitted  from  the 
global  invariant  and  every  assertion;  a  “AS. AS'.”  is  omitted  from 
every  assumption  and  guarantee.  In  these  predicates,  M  and  R  re¬ 
fer  to  the  memory  component  and  the  register  file  component  of  the 
bounded  variable  S  respectively,  and  M'  and  R'  refer  to  those  of  the 
bounded  variable  S'. 

For  this  example,  state  predicate  True  is  used  as  the  assertion  p  at 
some  of  the  yield  instructions,  because  Inv  alone  is  sufficient  in 
characterizing  the  states  at  these  points.  Moreover,  since  thread  1 
never  modifies  the  value  of  a2  or  cs2,  the  guarantee  Gi  can  be 
used  as  the  local  guarantee  g  throughout  the  code  of  thread  1.  Take 
the  code  block  labeled  cseci  as  an  example.  There  are  two  move 
instructions  used  to  put  intermediate  values  into  registers;  their  ef¬ 
fect  is  apparent  from  the  associated  assertions.  A  following  store 
instruction  writes  into  the  memory  location  csi,  after  which  the 
global  invariant  is  still  maintained.  It  is  a  simple  task  to  check  the 
well-formedness  of  this  code  block  with  respect  to  the  precondi¬ 
tions,  because  every  assembly  instruction  only  incur  little  change 
to  the  machine  state.  The  use  of  a  proof  assistant  helps  automate 
most  simple  steps  and  keep  the  would-be  arduous  task  manageable. 

4.2  Deadlock  Freedom 

One  way  to  prevent  deadlock  is  to  assign  a  total  ordering  to  all 
resources  and  stick  to  it  when  acquiring  them.  We  give  a  sim¬ 
plified  example  of  dining  philosophers  in  Figure  11,  where  two 
philosophers  (Threadi  and  Thread2)  share  two  forks  (represented 
by  memory  locations  forki  and  fork2).  A  philosopher  picks  up 
(acquire)  a  fork  by  writing  the  thread  id  (1  or  2)  into  the  mem¬ 
ory  location  representing  the  fork,  and  puts  down  (release)  a  fork 
by  writing  0.  Both  philosophers  acquire  forki  before  acquiring 
f  ork2. 


The  deadlock  freedom  property  for  this  example  can  be  expressed 
as  (fork2  =  0)  V  (fork2  =  forki),  indicating  that  either  a  fork  is 
free  or  a  philosopher  is  holding  both  forks.  In  the  more  general  case 
of  three  or  more  philosophers,  the  deadlock  freedom  property  can 
be  expressed  as  (f  orkn  =  0)  V  (3;.  f  ork^  =  forki),  where  n  is  the 
number  of  philosophers  and  f  orkn  is  the  “greatest  fork.”  Note  that 


Inv  =  (M(fork2)  =  0)  V  (M(fork2)  =  M(forki)) 

Ai,G2  =  (M'(fork2)  =  2  D  M'(forki)  =  2) 

A(M(forki)  =  1  ^  M'(f  orki)  =  1) 

A(M(fork2)  =  1  ^  M'(f  ork2)  =  1) 

A2,Gi  =  (M'(fork2)  =  1  D  M'(forki)  =  1) 

A(M(forki)  =  2  ^  M'(f  orki)  =  2) 

A(M(fork2)  =  2  ^  M^(f  ork2)  =  2) 

Initial  M  =  {forki  0,fork2  0} 

Initial  thread:  i  where  i  e  {1,2} 

Initial  instruction  sequences:  I,-  =  jd  fai 
Initial  precondition  triple:  (pi,P2,g)  =  ( 

M(f orki)  7^  1  AM(f ork2)  7^  1, 

M(f  orki)  7^  2  AM(f  ork2)  7^  2,Gi) 

fax  :  — {(M(forki)  7^  1  AM(fork2)  7^  l,Gi)} 

yield 

movi  ri ,  forki 
Id  r2,ri(0) 
movi  r3,0 
bgt  r2,r3,/ai 

—  {(M(forki)  =  0AM(fork2)  7^  1 

AR(ri)  =  forki, Gi)} 
movi  r2, 1 

—  {(M(forki)  =  0AM(fork2)  7^  1 

AR(ri)  =  forki  AR(r2)  =  1, 

(M'(fork2)  =  1  D  M'(forki)  =  1) 

A (M' (forki)  7^2) 

A(M(f  ork2)  =  2  ^  M'(fork2)  =  2))} 

Stri(0),r2 

—  {(M(forki)  =  1  AM(fork2)  7^  1, 

(M^(fork2)  =  1  D  (forki)  =  1) 

A (M' (forki)  7^  2) 

A(M(f  ork2)  =  2  ^  M^(fork2)  =  2))} 
yield 

—  {(M(forki)  =  1  AM(fork2)  7^  l,Gi)} 
jd/*i 

fb\  :  — {(M(forki)  =  1  AM(fork2)  7^  l,Gi)} 

yield 

movi  ri ,  f  ork2 
Id  r2,ri(0) 
movi  r3,0 
bgt  r2,r3,/Zii 
movi  r2, 1 
Stri(0),r2 

—  {(M(forki)  =  1  AM(fork2)  =  1, 

(M'(fork2)  =  1  D  M'(forki)  =  1) 

A (M' (forki)  7^2) 

A(M'(fork2)  7^2))} 

yield 

—  {(M(forki)  =  1  AM(fork2)  =  l,Gi)} 
movi  ri ,  f  ork2 

movi  r2,0 

stri(0),r2 

yield 

—  {(M(forki)  =  1  AM(fork2)  7^  l,Gi)} 
movi  ri ,  forki 

movi  r2,0 

Stri(0),r2 

yield 

—  {(M(forki)  7^  1  AM(fork2)  7^  l,Gi)} 
jd/fli 

Figure  12.  CCAP  implementation  for  dining  philosophers  algo¬ 
rithm. 


Variables:  Initially: 

nat  a,b;  a  =  aAb  =  (3 

Thread  1:  Thread2  : 

while  (a  ^  b)  while  (b  7^  a) 

if  (a  >  b)  if  (b  >  a) 

a:=a  — b;  b:=b  — a; 

Figure  13.  GCD  algorithm. 


we  cannot  use  CCAP  as  is  to  reason  about  livelock  or  starvation 
freedom,  which  are  liveness  properties  and  require  different  proof 
methods  [34]. 

The  corresponding  CCAP  specification  and  program  are  shown  in 
Figure  12,  where  the  same  notational  convention  is  used  as  estab¬ 
lished  in  the  previous  section,  and  only  the  code  for  Threadi  is 
given.  In  this  example,  Inv  is  exactly  the  desired  property.  Thread 

1  guarantees  (see  Gi)  to  acquire  f  ork2  only  after  acquiring  forki 
(M'(fork2)  =  1  D  M' (forki)  =  1)-  Due  to  the  nature  of  our  sim¬ 
ulation  using  the  values  of  forki  and  fork2  to  indicate  the  oc¬ 
cupiers  of  the  resources.  Thread  1  also  guarantees  that  it  does  not 
release  a  resource  held  by  Thread  2  or  acquire  a  resource  for  Thread 

2  (M.{forki)  =  2  ^  Ml  {forki)  =  2,  where  ^  means  “if  and  only 
if”).  The  case  for  Thread  2  is  similar. 

We  explain  the  code  block  labeled  fa\,  which  corresponds  to  the 
first  acquiring  operation  of  Threadi  ■  The  precondition  of  this  block 
indicates  that  Threadi  owns  neither  resource  at  the  beginning  of  the 
loop.  A  busy  waiting  on  forki  is  coded  using  the  branch  instruc¬ 
tion  (bgt).  During  the  waiting,  the  guarantee  is  trivially  maintained 
because  no  state  change  is  incurred.  The  thread  executes  past  the 
branch  instruction  only  if  forki  is  free,  i.e.,  M(forki)  =  0,  as 
captured  by  the  assertion  immediately  after  the  branch.  At  this 
point,  based  on  the  current  value  of  forki,  which  does  not  equal 
to  2,  we  can  simplify  the  local  guarantee  at  the  next  step  follow¬ 
ing  Rule  SIMPL.  The  difference  between  the  new  guarantee  and 
the  original  Gi  lies  in  the  handling  of  forki — the  new  guarantee 
requires  that  M' (forki)  7^  2,  because  it  is  known  that  the  original 
value  of  forki  was  not  2.  The  verification  of  the  remainder  of  this 
code  block  is  straightforward.  At  the  yielding  instruction  before 
jumping  to  fb\,  the  local  guarantee  is  instantiated  twice  on  the  cur¬ 
rent  state;  its  validity  is  trivial.  After  the  yielding  instruction,  the 
local  guarantee  is  reset  to  Gi  as  required  by  Rule  YIELD. 


4.3  Partial  Correctness 

We  consider  a  program  for  computing  a  Greatest  Common  Divi¬ 
sor  (GCD)  as  shown  in  Figure  13.  This  program  satisfies  the  par¬ 
tial  correctness  property  that  a  and  b  become  equal  to  the  GCD  of 
their  initial  values  when  the  program  exits  the  loop,  a  and  P  are 
rigid  variables  ranging  over  natural  numbers;  they  are  introduced 
for  reasoning  purposes. 

Figure  14  gives  the  corresponding  CCAP  specification  and  pro¬ 
gram.  Only  the  code  of  Threadi  is  shown.  The  global  invariant  of 
this  program  is  that  the  GCD  of  a  and  b  remains  the  same.  Thread] , 
for  example,  makes  the  assumption  that  Thread2  may  change  the 
values  of  a  or  b  only  if  M(a)  <  M(b)  and  only  in  such  a  way  that 
the  GCD  can  be  preserved.  The  partial  correctness  property  is  ex¬ 
pressed  as  the  precondition  of  the  code  block  labeled  done\ — if  the 
execution  ever  reaches  here,  the  value  stored  in  a  and  b  must  be  the 
expected  GCD. 


Let  6  be  a  shorthand  for  gcd(a,  (3). 

Inv  =  gcd(M(a),M(b))  =  5 

Ai,G2  =  (M(a)  >M(b)  D  (M(a)  =  M'(a)AM(b)  =M'(b))) 
A(M(a)  <  M(b)  D  (gcd(M'(a),M'(b))  =  5)) 

A2,Gi  =  (M(b)  >  M(a)  D  (M(a)  =  M(a)  AM(b)  =  M'(b))) 
A(M(b)  <  M(a)  D  (gcd(M'(a),M'(b))  =  5)) 

Initial  M  =  {a-^  a,b  (3} 

Initial  thread:  i  where  i  G  {1,2} 

Initial  instruction  sequences:  I,-  =  jd  loopi 
Initial  precondition  triple:  (pj,p2,g)  = 

(gcd(M(a),M(b))  =  5,gcd(M(a),M(b))  =  5,Gi) 


loopi  :  — {(True,Gi)} 
yield 

movi  ri,a 
Id  r2,ri(0) 
movi  r3,b 
Id  r4,r3(0) 
be  r2,r4,douei 
— {(True,Gi)} 
yield 

movi  ri,a 
Id  r2,ri(0) 
movi  r3,b 
Id  r4,r3(0) 
bgt  r2,r4,ca/ci 
— {(True,Gi)} 
yield 
jd  loopi 


calc\  :  — {(M(a)  >  M(b),Gi)} 

yield 

-{(M(a)  >M(b),Gi)} 

movi  ri,a 

—  {(M(a)  >M(b)  AR(ri)  =  a, 
gcd(M'(a),M'(b))  =5)} 
Id  r2,ri(0) 
movi  r3,b 
Id  r4,r3(0) 

SUbr5,r2,r4 

Stri(0),r5 

—{(True, 

gcd(M'(a),M'(b))  =8)} 

yield 
jd  loopi 

done\  :  — {(M(a)  =  M(b)  =  8,Gi)} 
yield 
jd  done  I 


Figure  14.  CCAP  implementation  for  GCD  algorithm. 


The  most  interesting  code  block  is  that  labeled  calci .  After  the  first 
yielding  instruction,  the  comparison  result  of  M(a)  >  M(b)  can  be 
used  to  simplify  the  next  local  guarantee  to  gcd(M'(a),M'(b))  =  6. 
The  actual  proof  of  this  certified  program  involves  also  apply¬ 
ing  mathematical  properties  such  as  gcd(a,a)  =  a  and  a  >  b  D 
gcd(a,b)  =  gcd(a  —  b,b). 

5  Implementation 

In  Section  2.1,  we  mentioned  the  use  of  Coq  and  the  underlying 
CiC  for  the  mechanical  verification  of  CAP  programs.  The  same 
approach  is  applied  to  implementing  CCAP.  We  encode  the  syntax 
of  CCAP  using  inductive  definitions,  and  define  the  operational  se¬ 
mantics  and  inference  rules  as  a  collection  of  relations.  Embedding 
the  entire  CCAP  in  Coq  allows  us  to  make  use  of  Coq’s  full  ex¬ 
pressiveness,  including  its  facility  for  inductive  definitions,  to  code 
the  verification  constructs  in  Figure  8.  This  also  allows  us  to  write 
down  the  soundness  lemmas  as  Coq  terms  and  formally  prove  their 
validity  as  theorems  using  the  Coq  proof  assistant.  In  particular, 
our  implementation  contains  about  350  lines  of  Coq  code  for  the 
language  definition  of  CCAP,  and  about  550  lines  of  Coq  tactics 
for  the  soundness  proof. 

We  have  also  verified  the  examples  of  Section  4  using  this  Coq 
encoding  (see  the  actual  code  [43]  for  details).  The  proof  con¬ 
struction  of  each  of  these  examples,  with  help  of  the  Coq  proof 
assistant,  took  no  more  than  a  few  hours.  On  average,  11.5  lines 
of  proof  in  Coq  tactics  is  written  for  every  assembly  instruction. 
As  we  have  expected,  many  premises  of  the  CCAP  inference  rules 
can  be  automatically  verified  given  the  intermediate  preconditions. 


This  is  especially  true  in  the  cases  of  simple  instructions  which  do 
not  concern  the  memory.  Human  “smartness”  is  required  occasion¬ 
ally,  however,  to  find  proper  intermediate  preconditions  and  apply 
mathematical  properties  such  as  those  of  the  GCD.  In  principle,  the 
programer  should  possess  informal  ideas  on  why  their  programs 
“work”  when  programming.  Our  system  simply  requires  the  pro¬ 
gramer  to  present  those  in  logic,  something  necessary  if  formal  rea¬ 
soning  is  desired. 

Keen  readers  may  have  observed  that  these  examples  do  not  involve 
any  data  structures,  hence  the  simplicity  in  verifying  them  is  not 
surprising.  Previous  work  [46,  47]  has  studied  similar  verification 
on  list-like  data  structures,  and  shown  that  the  verification  task  is 
also  straightforward  after  developing  proper  lemmas  detailing  the 
interaction  between  various  instructions  (in  particular  st)  and  data 
structures. 


6  Related  and  Future  Work 
6.1  Program  Verification 

The  CAP  languages  {i.e.,  CAP  and  CCAP)  approach  the  “verify¬ 
ing  compiler”  grand  challenge  from  the  aspect  of  program  verifica¬ 
tion.  They  are  developed  as  a  complementary  approach  to  Proof- 
Carrying  Code  (PCC)  [29,  28]  where  the  safety  proof  of  a  program 
is  developed  semi-automatically  by  the  programmer  with  help  of 
a  proof  assistant.  The  human  factor  involved  achieves  safety  in  a 
more  general  sense,  allowing  the  verification  of  even  undecidable 
program  properties.  Some  useful  applications  include  core  system 
libraries  and  critical  software  components.  Much  further  work  is 
required,  however,  on  improving  the  modularity  of  the  CAP  lan¬ 
guages  before  they  can  be  applied  to  large  scale  applications.  This 
work  includes  modular  support  for  higher-order  code  pointers  (see 
Section  6.3)  and  safe  linking  of  software  components  [14].  In  the 
long  run,  it  is  conceivable  to  develop  verified  software  components 
one  by  one  and  eventually  have  even  a  complete  operation  system 
verified.  The  modularity  support  for  the  CAP  languages  will  be 
crucial  in  realizing  this  ambition. 

The  CAP  languages  address  program  safety  directly  at  the  level  of 
machine  code.  The  code  being  verified  is  so  close  to  the  actual  ex¬ 
ecutable  that  the  translation  between  them  is  very  trustworthy.  This 
contrasts  with  model  checking,  which  operates  on  models  of  pro¬ 
grams.  The  non-trivial  abstraction  step  to  construct  a  model  from  a 
program  indicates  that  a  verified  model  may  not  necessarily  imply  a 
verified  program.  On  the  other  hand,  focusing  on  high-level  models 
enables  model  checking  to  be  effective  in  practice. 

Type  systems  are  another  popular  approach  of  reasoning  about  pro¬ 
grams.  Types  document  programmers’  intent  and  enable  compil¬ 
ers  to  detect  certain  programming  errors  automatically.  In  practice, 
type  systems  have  only  been  applied  to  reasoning  about  a  limited 
scope  of  properties,  including  non-stuckness  of  programs,  infor¬ 
mation  flow,  finite-state  rules,  races  and  deadlocks,  and  atomicity 
of  multithreaded  programs.  In  essence,  types  are  simply  restricted 
predicates,  and  the  complexity  of  a  type  system  is  determined  by  the 
complexity  of  the  underlying  property  that  it  enforces.  This  makes 
it  hard  to  apply  type  systems  to  low-level  code  such  as  those  found 
in  storage  allocation  libraries,  whose  properties  often  demand  very 
specialized  type  systems.  The  CAP  languages,  in  contrast,  directly 
employ  higher-order  predicate  logic,  intending  to  formally  present 
the  reasoning  of  a  programmer.  Proof  construction  is  not  unduly 
difficult  with  help  of  a  proof  assistant. 


Shao  et  al.  [39]  developed  a  type  system  for  certified  binaries 
(TSCB).  An  entire  proof  system  (CiC)  is  integrated  into  a  compiler 
intermediate  language  so  as  to  perform  reasoning  about  certified 
programs  in  a  calculus  but  essentially  using  higher-order  predicate 
logic  via  the  formulae-as-types  principle  [22],  Being  a  type  system, 
the  soundness  of  TSCB  only  guarantees  type-safety  (non-stuckness 
of  well-typed  programs).  In  comparison,  the  CAP  languages  allow 
programmers  to  write  arbitrary  predicates  in  the  specification  to  ac¬ 
count  for  more  general  safety  properties.  Another  convenient  trait 
of  the  CAP  languages  is  that,  using  a  proof  assistant  like  Coq,  the 
well-formedness  reasoning  can  be  performed  without  the  knowl¬ 
edge  about  the  CiC  calculus,  which  may  be  desirable  to  some  pro¬ 
grammers. 


6.2  Concurrency  Verification 

There  has  been  much  work  on  concurrency  verification  (see  [9,  21] 
for  a  systematic  and  comprehensive  introduction).  This  paper 
adapts  and  applies  established  techniques  on  this  issue  for  assembly 
code,  a  domain  not  covered  by  existing  work.  The  proof  methods 
pertinent  to  this  paper  have  been  discussed  in  Sections  2.2  and  2.3. 
In  particular,  our  modeling  has  benefited  from  previous  work  by 
Lamport  [24]  and  Flanagan  et  al.  [1 1],  as  elaborated  below. 

Lamport  [24]  proposed  the  Temporal  Logic  of  Actions  (TLA)  as  a 
logic  for  specifying  and  reasoning  about  concurrent  systems.  He 
pointed  out  a  unified  view  of  existing  methods  for  proving  invari¬ 
ance  (safety)  properties,  which  can  be  described  formally  in  TLA 
as  applications  of  a  temporal  inference  rule  named  INVl.  Some 
simple  temporal  reasoning  following  INVl  shows  that  a  general  in¬ 
variance  proof  can  be  reduced  to  finding  an  invariant  1  satisfying 
three  conditions.  All  these  conditions  are  assertions  about  predi¬ 
cates  and  actions,  rather  than  temporal  formulas;  hence  the  proof 
for  invariance  properties  can  be  completed  in  ordinary  mathematics 
following  the  three  conditions. 

CCAP  engaged  a  “syntactic  approach”  usually  found  in  type  sys¬ 
tems.  Well-formedness  of  the  program  is  used  as  the  invariant 
/,  and  the  soundness  lemmas,  namely  progress  and  preservation, 
cover  two  of  the  conditions.  The  last  condition,  i.e.,  initial  well- 
formedness  of  the  program,  is  left  for  the  programmer  to  establish 
using  “typing”  rules  (inference  rules).  It  is  not  difficult  to  see  that 
the  lack  of  temporal  reasoning  in  CCAP  does  not  limit  its  expres¬ 
siveness  in  proving  for  safety  properties,  following  the  observation 
from  TLA. 

Proving  liveness  properties,  on  the  other  hand,  requires  further 
work.  Existing  work  handles  liveness  properties  using  counting- 
down  arguments  or  proof  lattices  [34].  As  observed  by  Lam¬ 
port  [24],  although  liveness  properties  are  expressed  by  a  variety 
of  temporal  formulas,  their  proofs  can  always  be  reduced  to  the 
proof  of  leads-to  properties — formulas  of  the  form  P'^  Q.  It  is  an 
interesting  future  work  to  investigate  how  to  apply  these  existing 
approaches  to  the  mechanical  verification  of  assembly  code. 

Flanagan  et  al.  [11]  investigated  the  mechanical  checking  of  proof 
obligations  for  Java  programs.  Their  automatic  checker  takes  as 
input  a  program  together  with  annotations  describing  appropriate 
assumptions,  invariants  and  correctness  properties.  The  key  tech¬ 
niques  used  by  the  checker,  including  assume-guarantee  decompo¬ 
sition,  are  derived  from  a  parallel  language  of  atomic  operations. 


6.3  Higher-Order  Code  Pointers 

Focusing  on  concurrency  verification,  we  have  left  out  from  this 
paper  the  orthogonal  issue  of  higher-order  code  pointers.  Higher- 
order  code  pointers  are  the  reflection  of  higher-order  procedures  at 
the  assembly  level,  and  a  common  example  is  the  return  pointers 
which  are  frequently  used  in  most  programs.  Unfortunately,  to  the 
authors’  knowledge,  the  modularity  support  for  higher-order  code 
pointers  (or  procedures)  in  Hoare-logic  systems  has  been  a  long¬ 
standing  open  problem. 

A  preliminary  support  for  higher-order  code  pointers  in  CAP  can  be 
found  in  previous  work  [46,  47].  However,  the  solution  there  is  not 
sufficiently  modular.  Take  a  library  function  as  an  example,  both 
the  caller’s  resource  and  the  callee’s  resource  need  to  be  explicitly 
written  in  the  code  heap  specification  for  a  CAP  routine.  Since  a 
library  function  is  to  be  called  at  various  places,  its  code  heap  spec¬ 
ification  entry  in  CAP  is  essentially  a  template  to  be  instantiated 
upon  used. 

Yu  et  al.  [48]  encountered  the  problem  of  “functional  parameters” 
when  checking  the  correctness  of  MC68020  object  code  programs. 
They  handle  it  by  asserting  the  correctness  of  the  functional  param¬ 
eters  using  “constraints.”  The  correctness  of  the  program  is  proved 
assuming  these  constraints,  and  the  correctness  theorem  of  the  pro¬ 
gram  is  used  repeatedly  by  substituting  the  functional  parameters 
with  specific  functions  as  long  as  these  functions  meet  the  imposed 
constraints.  Although  plausible,  the  actual  mechanization  of  this 
idea,  as  explained  by  Yu  et  al.  [48],  is  “extremely  difficult.”  Fur¬ 
thermore,  this  approach  is  not  truly  satisfactory  because  the  specifi¬ 
cation  of  a  program  and  its  correctness  theorem  are  essentially  tem¬ 
plates  which  need  to  be  instantiated  upon  used.  CAP’S  approach,  as 
describe  earlier,  is  very  close  to  this:  the  actual  code  heap  specifi¬ 
cation  is  used  when  forming  the  “constraints.”  In  practice,  we  find 
it  awkward  when  certifying  programs  with  extensive  use  of  code 
pointers,  especially  when  these  uses  are  unconventional  compared 
with  return  pointers. 

Similar  problems  surfaced  in  some  PCC  systems  as  well.  In  par¬ 
ticular,  Configurable  PCC  (CPCC)  systems,  as  proposed  by  Nec- 
ula  and  Schneck  [30],  statically  check  program  safety  using  sym¬ 
bolic  predicates  which  are  called  “continuations.”  For  checking  the 
safety  of  an  indirect  jump  instruction  which  transfers  the  program 
control  given  a  code  pointer,  a  trusted  “decoder”  generates  an  “in¬ 
direct  continuation”  whose  safety  needs  to  be  verified;  this  continu¬ 
ation  is  indirect  because  the  target  address  cannot  be  determined  by 
the  decoder  statically.  For  verification  purpose,  an  untrusted  “VC- 
Gen  extension”  is  responsible  for  proposing  some  “direct  contin¬ 
uations”  (direct  meaning  that  the  target  addresses  are  known  stati¬ 
cally)  whose  safety  implies  the  safety  of  the  “indirect  continuation” 
given  by  the  decoder.  In  practice,  the  extension  works  by  listing 
all  the  possible  values  of  the  code  pointer  (essentially  replacing  the 
code  pointer  in  the  continuations  with  all  concrete  functions  that  it 
could  stand  for),  which  requires  whole-program  analysis  and  hence 
is  contradictory  with  the  goal  of  modularity. 

Chang  et  al.  [6]  presented  a  refined  CPCC  system  in  which  “lo¬ 
cal  invariants”  refine  “continuations.”  A  local  invariant  essentially 
consists  of  two  related  components — an  “assumption”  of  the  cur¬ 
rent  state  and  a  list  of  “progress  continuations”  which  are  used  for 
handling  code  pointers.  To  allow  the  VCGen  extension  to  manipu¬ 
late  predicates  using  first-order  logic,  only  a  syntactically  restricted 
form  of  invariants  are  used.  Although  this  is  necessary  for  auto¬ 
matic  proof  construction  for  type-safety,  it  is  insufficient  in  han¬ 
dling  higher-order  code  pointers  in  general.  As  a  result,  these  local 


invariants  are  only  used  to  handle  more  gracefully  certain  fixed  pat¬ 
terns  of  code  pointers,  such  as  return  pointers.  Other  situations, 
such  as  virtual  dispatch,  would  still  require  whole-program  anal¬ 
ysis  for  the  VCGen  extension  to  discharge  the  decoder’s  indirect 
continuations.  In  particular,  it  is  unclear  how  this  approach  extends 
to  support  arbitrary  safety  policies  and  nested  continuations. 

Reynolds  [38]  identified  a  similar  problem  in  separation  logic  and 
referred  to  it  as  “embedded”  code  pointers,  which  are  “difficult 
to  describe  in  the  first-order  world  of  Hoare  logic.”  He  specu¬ 
lated  that  a  potential  solution  lies  in  marrying  separation  logic  with 
continuation-passing  style.  The  idea  was  only  described  briefly 
and  informally,  and  a  convincing  development  remains  yet  to  come 
forth.  Recently,  O’Hearn  et  al.  [31]  investigated  proof  rules  for 
modularity  and  information  hiding  for  first-order  procedures  using 
separation  logic.  However,  it  is  unclear  how  their  approach  extends 
to  support  higher-order  features.  It  is  also  worth  mentioning  that 
related  problems  on  higher-order  procedures  in  Hoare  logic  can  be 
traced  back  to  the  late  seventies  [7,  8]. 

We  are  currently  working  on  a  system  which  addresses  this  issue 
more  properly.  It  involves  a  unified  framework  for  type  systems  and 
Hoare  logic,  and  allows  reasoning  using  both  types  and  predicates. 
A  similar  idea  on  deploying  a  logic  in  a  type  system  for  an  assembly 
language  is  due  to  Ahmed  and  Walker  [3].  We  intend  to  present 
this  work,  which  is  sufficiently  interesting  and  self-contained,  in  a 
separate  paper. 

6.4  Other  Future  Work 

CCAP  is  based  on  an  abstract  concurrent  machine  which  shields 
us  from  the  details  of  thread  management  such  as  creation  and 
scheduling.  However,  many  concurrent  programs  are  executed  on 
sequential  machines,  relying  on  thread  libraries  to  take  charge  in 
thread  management.  One  interesting  possibility  is  to  implement  a 
certified  thread  library  using  a  sequential  CAP  language  by  veri¬ 
fying  the  implementation  of  thread  primitives,  which  are  really  se¬ 
quential  programs  with  advanced  handling  of  code  pointers.  This 
work  helps  bring  CCAP  to  a  more  solid  ground  regarding  trustwor¬ 
thy  computing. 

We  are  also  working  on  the  application  of  the  CAP  languages  to  a 
realistic  machine  model,  such  as  the  Intel  Architecture  (x86).  The 
intention  is  to  verify  the  very  same  assembly  code  as  those  running 
on  actual  processors.  Our  experience  indicates  that  the  tasks  in¬ 
volved  here  are  mostly  engineering  issues,  including  the  handling 
of  fixed-size  integers,  byte-aligned  (as  opposed  to  word-aligned) 
addressing  mode,  finite  memory  model  (restricted  by  word-size), 
and  encoding  and  decoding  of  variable-length  instructions.  We  be¬ 
lieve,  however,  that  these  aspects  are  orthogonal  to  the  reasoning  of 
most  program  properties  of  interest  and  hence  their  handling  can  be 
facilitated  with  proper  proof  libraries. 

7  Conclusion 

We  have  presented  a  language  CCAP  for  verifying  safety  proper¬ 
ties  of  concurrent  assembly  code.  The  language  is  modeled  based 
on  a  concurrent  abstract  machine,  adapting  established  techniques 
for  concurrency  verification  at  an  assembly  level.  CCAP  has  been 
developed  using  the  Coq  proof  assistant,  alone  with  a  formal  sound¬ 
ness  proof  and  the  verified  example  CCAP  programs.  Only  small 
examples  are  given  in  this  paper  for  illustrative  purposes,  but  prac¬ 
tical  applications  are  within  reach,  especially  for  small-scale  soft¬ 
ware  such  as  core  libraries,  critical  components  or  embedded  sys¬ 


tems.  Its  potential  application  to  large-scale  software  calls  for  a 

further  development  on  modularity. 
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Figure  15.  Syntax  of  a  generalized  CCAP. 


Technology  and  Theoretical  Computer  Science,  volume  206  of  LNCS, 
pages  369-391,  New  Delhi,  1985.  Springer- Verlag. 

[41]  C.  Stirling.  A  generalization  of  Owicki-Gries’s  Hoare  logic  for  a  con¬ 
current  while  language.  Theoretical  Computer  Science,  58(l-3):347- 
359,  1988. 

[42]  The  Coq  Development  Team.  The  Coq  proof  assistant  reference  man¬ 
ual.  The  Coq  release  v7.1,  Oct.  2001. 

[43]  The  FLINT  Project.  Coq  (v7.3.1)  implementation  for  CCAP  language, 
soundness  and  examples,  http://fliiit.cs.yale.edu/flint/ 
publications/vsca.html  (17k),  Mar.  2004. 

[44]  A.  K.  Wright  and  M.  Felleisen.  A  syntactic  approach  to  type  sound¬ 
ness.  Information  and  Computation,  1 15(l):38-94,  1994. 

[45]  Q.  Xu,  A.  Cau,  and  P.  Collette.  On  unifying  assumption-commitment 
style  proof  rules  for  concurrency.  In  International  Conference  on  Con¬ 
currency  Theory,  pages  267-282,  1994. 

[46]  D.  Yu,  N.  A.  Hamid,  and  Z.  Shao.  Building  certified  libraries  for  PCC: 
Dynamic  storage  allocation.  In  Proc.  2003  European  Symposium  on 
Programming,  LNCS  Vol.  2618,  pages  363-379,  Warsaw,  Poland,  Apr. 
2003.  Springer- Verlag. 

[47]  D.  Yu,  N.  A.  Hamid,  and  Z.  Shao.  Building  certified  libraries  for 
PCC:  Dynamic  storage  allocation.  Science  of  Computer  Program¬ 
ming,  50(1-3):  101-127,  2004. 

[48]  Y.  Yu.  Automated  proofs  of  object  code  for  a  widely  used  micropro¬ 
cessor.  PhD  thesis.  University  of  Texas  at  Austin,  Austin,  TX,  1992. 

A  CCAP  with  Multiple  Threads 

The  CCAP  presented  in  Section  3  supports  only  two  threads,  which 
is  easy  to  understand  yet  sufficient  in  demonstrating  all  the  key 
ideas.  This  appendix  gives  a  generalized  account.  Figures  15  and  16 
give  the  syntax  and  operational  semantics  of  a  generalized  CCAP 
supporting  more  than  two  threads.  The  auxiliary  state  update  macro 
is  the  same  as  shown  in  Figure  7.  Inference  rules  and  soundness 
lemmas  follow.  In  particular,  a  generalized  inference  rule  for  well- 
formed  program  is  given  to  support  multiple  threads.  The  inference 
rules  for  well-formed  code  heap  and  well-formed  instruction  se¬ 
quence,  in  contrast,  remain  exactly  the  same  as  in  the  two-threaded 
version  (these  rules  are  gathered  here  for  ease  of  reference).  This 
demonstrates  that  CCAP  is  indeed  thread-modular. 


((M,IR),  [. . .  (C/,11/) . . .], 0  1 — ^  P  where 

if  I;  = 

then  P  = 

jdf 

((M,R),  [. ..  (C;, I') ..  .],;■)  where  C,'(f )  =  I' 

yield;!' 

((M,R),  [. . .  (C;,r) . .  .J,;')  where  ;'  G  {1 . .  .n| 

bgt  ri,ri,f;r 

((M,R),  [. . .  (C;,I') . . .  J, ;)  when  R(rj)  <  R(ri);  and 

((M,R),  [. . .  (Ci,I") ...],;)  when  R(rj)  >  R(ri)  where  Ci(f )  =  I" 

be  rj,rf,f;I' 

((M,R),  [. . .  (Ci,F) . . .  J, ;)  when  R(rj)  y/:  R(ri);  and 

((M,R),  [. . .  (C;,I") ...],;)  when  R(rj)  =  R(ri)  where  Ci(f )  =  I" 

c;I'  for  remaining  cases  of  c 

(Next(c,(M,R)),[...(C, ■,!'). ..|,;) 

Figure  16.  Operational  semantics  of  a  generalized  CCAP. 


Note  that  we  do  not  support  the  dynamic  creation  and  termination 
of  threads  in  this  language,  but  extensions  on  them  are  natural  and 
have  little  to  do  with  the  concurrency  verification  techniques  pre¬ 
sented  in  this  paper.  To  be  specific,  even  for  a  dynamically  created 
thread,  the  code  has  to  be  written  beforehand,  and  the  behavior  has 
to  obey  the  global  invariant,  the  assumptions  and  the  guarantees. 
Hence  the  thread’s  counterparts  exist  statically  in  the  code  heap  and 
the  specification.  The  safety  reasoning  used  for  a  CCAP  program 
remains  unchanged,  no  matter  how  many  individual  threads  are  cre¬ 
ated  for  the  same  code.  Therefore,  the  addition  of  thread  creation 
and  termination  mostly  affects  the  operational  semantics,  and  the 
inference  rules  can  be  adapted  with  little  effort. 


0  =  (/nv,*?,  A,G) 

VM.VR.  (/nvAp  (M,R))  D  ((R(rj)  +w)  G  dom(M)) 
VS.  (/nvAp  S)  D  (/nv  Ap'  Next(c,S)) 

VS.  VS'.  (/nvAp  S)  D  (g'  Next(c,S)  S')  D  (g  S  S') 

0;(p',g')|-I  c  =  strrf(w),r^ 


0;(p,g)  1“ 


(ST) 


0=(/mv,'P,A,G)  'P(f)  =  (p',g') 

VS.(/«vApS)D(p'S) 

VS. VS',  (/nv  Ap  S)  D  (g'  S  S')  D  (g  S  S') 
0;  (p,g)  i-jd  f 


Well-formed  program 


‘^’;([pi--'P«l.g) 


4>  =  (/nv,  ['Pi  [Ai . . .  A„],  [Gi . .  .G„l) 

0J,  =  (/nv,  'Pi;,  Aj,,Gl;)  ©1;  h  Cl;  Vfee{l...n} 
(/nvApiS)  VS".(gSS")D(piS")  Vk^i 
VS'. VS".  (/nvAp,t  S')  D  (A,i  S'  S")  D  (pi  S")  Vk  ^  i 
0i;(Pi,g)|-Ii  0l;;(p,t,Gl;)  hll; 

<5;([Pi...pJ,g)V(S,[(Ci,Ii)...(C„,I„)],0 


Well-formed  code  heap 

0  =  (/nv,'P,A,G) 

'P  =  {f;-(p^,g^)}Mi.-} 

0;(Pj>gj)  Vy'e{l---ni} 
01- 

Well-formed  instruction  sequence 


0=  (/nv,'P,A,G) 
VS.(/nvApS)D(gSS) 

VS.  VS',  (/nv  A p  S)  D  (A  S  S')  D  (p  S') 
0;(p,G)  hi 

0;(p,g)  hyield;! 


0h  C 


(CODEHEAP) 


0;(p,g)^i 


(YIELD) 


0=  (/nv,'P,A,G) 

VS.  (/nvAp  S)  D  (/nv  Ap'  Next(c,S)) 

VS.  VS'.  (/nvAp  S)  D  (g'  Next(c,S)  S')  D  (g  S  S') 
0;(p',g')hl  c  G  {add,sub,movi} 


0;(p,g)  1“ 


(SIMPL) 


0=  (/nv,'P,A,G) 

VM.VR.  (/nvAp  (M,R))  D  ((R(rj)  -fw)  G  dom(M)) 
VS.  (/nv  Ap  S)  D  (/nvAp'  Next(c,S)) 

VS.  VS',  (/nv  A  p  S)  D  (g'  Next (c,  S)  S')  D  (g  S  S') 
0;(p',g')hl  c  =  ldrj,r^(w) 


0;(p,g)  1“ 
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D(g'  (M,R)  S')D(g  (M,R)  S') 

VM.VR.  (R(r,)  <  R(rr))D(/nvAp  (M,R))d(p"  (M,R)) 
VM.VR.VS'.(R(r,)  <R(rr))D(/nvAp  (M,R)) 

D(g"  (M,R)  S')D(g  (M,R)  S') 

0;(p".g")n _ 

0;(p,g)  1“  bgt  ri,rr,f;I 

(BGT) 


0=(/nv,'P,A,G)  'P(f)  =  (p',g') 

VM.VR.  (R(r,)  =R(rr))D(/nvAp  (M,R))d(p'  (M,R)) 
VM.VR.VS'.(R(r,)  =R(rr))D(/nvAp  (M,R)) 

D(g'  (M,R)  S')D(g  (M,R)  S') 
VM.VR.(R(r,)  7^R(ri))D(/nvAp  (M,R))d(p"  (M,R)) 
VM.VR.VS'.(R(r,)  7^R(ri))D(/nvAp  (M,R)) 

D(g"  (M,R)  S')D(g  (M,R)  S') 

0;(p",g")hl 


0;(p.g)  b  be  rj,r,,f;I 
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Lemma  5  (Progress)  Let 

<P  =  (/nv,  [*Pi . . . 'P„],  [Ai . . .  A„],  [Gi . . . G„]).  If 
‘^’;([Pl  •••P«].g)  1“  (S,[(Ci,Ii)...(C„,I„)],i)  where;  G  {l...n}, 
then  (/nv  S)  and  there  exists  a  program  P  such  that 
(S,[(Ci,Ii)...(C„,I„)],;)^P. 

Lemma  6  (Preservation)  Let 

<!'  =  (/nv,  [*Pi . .  .*P„],  [Ai . . .  A„],  [Gi . .  .G„]).  Suppose 
VS'.  VS".  (Gy  S'  S")  D  (Ai  S'  S")  for  all  j  ^  k.  If 
‘J’;([Pl  •••P«].g)  1“  (S,[(Ci,Ii)...(C„,I„)],;)  where;  G  {l...n}, 
and  (S,  [(Cl ,Ii) . . .  (C„,I„)], ;)  i — >  P,  then  there  exists  p),. . . ,p'„ 
and  g'  such  that  d>;  ( [p'j . . .  p),] ,  g')  h  P. 


(LD) 


